1. Field of the Invention
This invention relates to networking, and more particularly to detecting the presence entities in a distributed networking environment.
2. Description of the Related Art
Presence in a decentralized networking environment is difficult to establish and scale without a central server. In a distributed environment, presence is manageable with a small number of nodes and presence entities. However, it becomes more difficult to establish presence in a decentralized environment as the number of nodes and presence entities on the network grows.
In a decentralized networking environment, some servers may provide presence services that may be used by entities to locate other presence entities and to negotiate contracts between the entities. Conventionally, presence entities always communicate with the central presence service that maintains the presence information. Contact is maintained between the presence entity and the presence service. When another entity is interested in a presence entity, it communicates with the presence service rather than with the presence entity itself, both for locating the presence entity and for contract negotiation.
An example of a conventional presence entity is AOL's AIM instant messenger service. A conventional presence service such as AIM, which may have thousands of servers which may perform tasks such as determining what regions presence entities are in, what presence entities such as services are available, and contract negotiations, may require considerable compute resources and storage to support a large network.
JXTA™
Sun's JXTA™ is an exemplary peer-to-peer platform. Peer-to-peer platforms such as JXTA may provide protocols for building networking applications that thrive in dynamic environments. JXTA technology is a set of open protocols that allow any connected device on the network ranging from cell phones and wireless PDAs to PCs and servers to communicate and collaborate in a peer-to-peer (P2P) manner. JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports. In JXTA, every peer is identified by an ID, unique over time and space. Peer groups are user-defined collections of entities (peers) that may share a common interest. Peer groups are also identified by unique IDs. Peers may belong to multiple peer groups, discover other entities and peer resources (e.g. peers, peer groups, services, content, etc.) dynamically, and publish themselves and resources so that other peers can discover them.
Shared Resource Distributed Index (SRDI)
Conventionally, JXTA provides a mechanism to query peers for shared resources (such resources include, but are not limited to, advertisements and pipe instances). Queries are propagated in a semi-controlled fashion, without any discretion as to whether the receiving end would likely have a response or not. In situations where a query cannot be fulfilled, the query may potentially reach every peer several times.
SRDI provides a generic mechanism that JXTA services may utilize to distribute indices of shared resources with other peers that are grouped as a set of more capable peers, such as rendezvous peers. These indices may be used to direct queries in the direction where the query is most likely to be answered, and to re-propagate messages to peers interested in the propagated messages.
JXTA services that expose resources, such as Discovery and Pipe services (or any other service implementing the SRDI interface) may, on initial connection to a rendezvous, share a list of entries describing the resources for which they choose a broader exposure. In addition, at a configurable interval (or at the creation of the resource), deltas may be uploaded to the rendezvous, and coalesced. The rendezvous peer then stores/hashes these key/value pairs. In addition, the receiving peer (through a hash function coupled with the RPV (Rendezvous Peer View)) selects a rendezvous where these entries are replicated; this same function would later be used in directing queries.
The rendezvous leverages the mechanism of its relationship with the peer to garbage collect indices/hashes when a peer severs the session with the rendezvous. In the event of rendezvous failure, the edge peer attempts to reconnect to another rendezvous, and indices of shared resources are republished on the new rendezvous.
Each entry may carry an absolute expiration time expressed in milliseconds, which is converted to a relative time by the receiving peer. Expired entries are garbage collected at a configured interval, or when the cache reaches a high water mark, whichever is sooner.
Local neighborhood queries are propagated to neighboring peers (using what a transport defines as the broadcast/multicast method). Local peers receiving the query would behave conventionally. A query that goes beyond a local neighborhood query may be sent to connected rendezvous peers; a rendezvous peer may attempt to satisfy the query against the local cache. If there is no match against local cache, the query may be compared against a lists of stored/hashed key/values for a possible match; the query is then forwarded to where the match(es) are. Since queries may define a threshold, the discretion of honoring the threshold is left up to the rendezvous peer, and ultimately the queried peer. If this does not produce a result, the query may be mapped to a starting point of the RPV (Rendezvous Peer View). A Limited Range Walker may be utilized to re-propagate the query within the RPV. Once the query reaches a peer that may be able to respond, the peer replies directly to the originator of the query.
Indices may be replicated among rendezvous peers through a SHA1 hash of the entries modulus the RPV (Rendezvous Peer View); this provides an independent mapping of queries, without the need of a highly consistent RPV. The combination of direct routing of queries (using the map function), and use of a failover mechanism of a Limited Range Walk yields an efficient query and message routing mechanism without the need for a highly consistent/fault tolerant system.
For edge peers, queries may be propagated using an Edge Peer Walker mechanism (local multicast, and propagation to connected rendezvous). For rendezvous peers, using SRDI, a direct route is attempted within the scope of the rendezvous, otherwise the mapping function derived from the query may be used to provide a starting point of the query re-propagation, after which (if a direct query route is not found) a Limited Range Walker may be used to re-propagate the query.
For edge peers, messages may be propagated using an Edge Peer Walker mechanism (local multicast, and propagation to connected rendezvous). For rendezvous peers, propagated messages may be re-propagated to a list of peers (derived from SRDI, a list of peers that are listening on the destination propagate pipe), and re-propagated to other rendezvous using a Random Walker.
In JXTA, services that wish to utilize the SRDI mechanism may implement the Resolver SrdiHandler and register with the ResolverService. The ResolverSrdi message is a generic envelope that defines the Handlemame (service id), and the credential document associated with the message; however, it does not define the payload. A generic SRDI message for the Discovery Service and the Pipe Service may be provided. A service may implement its own SRDI payload that best fits its need.
Resolver Service
JXTA provides a mechanism for querying for resources and/or routing messages on the P2P network through a resolver service implemented according to one or more JXTA resolver protocols. A resource on a P2P network (which may be a service, an application, a peer, or any other presence on the P2P network) may register one or more resource handlers with a resolver service. The resource handlers may respond to incoming queries by parsing each query and generating a response message to the query. A peer node may send a query message, formatted in accordance with the resolver protocol, for a resource to a resolver service implemented on a node in the P2P network. The query message may include one or more of, but is not limited to, a credential for the querying peer node, a query identifier, a query, and a handler name that may identify a particular resource handler.
Upon receiving a query message, a resolver service may determine which of the resource instances is to receive the query message. The determination may be made using one or more of a variety of criteria to determine an optimal resource instance to receive the query using the particular criteria. The resolver service may then forward the query message to the resource handler indicated in the query message on a determined resource instance. The resource handler may parse the query included in the query message and generate a response to the query. The resource handler on the determined resource instance may then send a response message including the response to the resolver service. Alternatively, the resource handler may send the response message to the querying peer node. Alternatively, the resource instance may not use the resource handler; the resource instance may instead receive the query message, generate a response message, and send the response message to a resolver service or the peer node. The resolver service may receive the response message and forward it to the querying peer node. A response message may include one or more of, but is not limited to, the credential of the peer node hosting the resource instance, the query identifier, the handler name, and the response that includes the information requested by the query.